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REMARKS 

Reconsideration and allowance of the subject application are respectfully requested. 

Claims 1-20 stand rejected over newly-cited and applied Spellman in view of newly-cited 
and applied Kubota. This rejection is respectfully traversed. 

There are several known techniques for storing a large number of documents in a 
database. A single document in the database may contain references to other documents, 
graphics files, and/or sound files of the same database or even to a separate database. An 
example of such a document is an HTML document widely used in the Internet/World Wide 
Web (WWW) environment. Typically, a database of HTML documents is stored on a web 
server connected to the World Wide Web. A user can browse documents stored in the database 
at the web server using a web browser. Typically, the web server receives a uniform resource 
locator (URL) request from the web browser, decodes URL, handles the document files, and 
sends the requested files to the web browser. It is also possible to browse documents locally in a 
local file system in a stand-alone data processing device that is not connected to the World Wide 
Web. In this case, the document address corresponding to a local file path is given to the local 
file system which then retrieves the file for the browser. 

These conventional arrangements are problematic in a situation where a document 
database has been configured so that a set of multiple documents is stored as a single file . 
Typically, the browser can only access separate documents located at a given URL address. But 
in a single file database structure, those documents stored in the single file can not be accessed in 
this traditional fashion. 

Nevertheless, there is a significant advantage to structuring a database that includes 
thousands of individual documents by storing them as a single file. A single file can be managed 
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much more easily than thousands of separate files, some of which may be of different file types. 
Moreover, the single file is more readily assigned a product identity and a version identifier, 
facilitating guarantee of the quality of the information contained in the database through proper 
version handling. 

Each of the multiple documents in a single file database typically contains links to other 
documents in that database. This creates a problem if it is desired to make the database 
transferable to different locations. In other words, the document links must be defined and 
handled so that a location-independent database can be achieved. Moreover, it would 
advantageous if the single file database could be defined so that the same database management 
could be used in a network context (the database could be copied to any network server), and a 
local file system in a stand-alone data processor (the database could be copied to any file path in 
the file system). 

The present invention solves these problems and achieves these desirable objectives by 
storing the multiple documents in a single file database using a specialized protocol. A non- 
limiting example of this single file database protocol is set forth in the detailed description 
starting on page 1 1 and is referred to as 'edw'. But the browser does not understand a 
specialized, single file database syntax. Accordingly, the references in the documents (e.g., 
URL's) must be transformed before a document in the database can be provided to the browser 
for display. This is true for a network server application and for a stand-alone data processor 
application. 

The Examiner admits that Spellman fails to disclose a single file database to store 
multiple documents. Although the Examiner relies upon Kubota, the Examiner does not identify 
what text in Kubota is being relied upon. The database 202 described in column 9, lines 38-43: 
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stores a plurality of documents such as a database of newspaper 
accounts, or a database of patent publications. However, it should 
be noted the application of the present invention is not limited to 
search of a database consisting of a plurality of documents, but 
includes searching a single document. 

Searching a single document is not the same thing as browsing "a database consisting of a set of 
documents stored electronically as a single file, at least one of the documents contain links to 
others of the documents." 

There is certainly no recognition, either in Spellman or in Kubota, of the problems of 
using such a single file database when documents are retrieved by web browsers. The Federal 
Circuit requires consideration of the problem confronted by the inventor in determining whether 
it would have been obvious to combine references in order to solve that problem. Northern 
Telecom, Inc. v. Datapoint Corp., 908 R2d 931, 935 (Fed. Cir. 1990). Indeed, the Examiner 
must show reasons why one of ordinary skill in the art, confronted with the same problem as the 
inventor and with no knowledge of the claimed invention, would select the elements from the 
cited prior art references for combination in the manner claimed. See In re Rouffet, 149 F.3d 
1350, 1357 (Fed. Cir. 1998). 

The Examiner fails to show that either Spellman or Kubota recognized or were 
confronted with the same problem as the instant inventors. Absent that recognition, it is clear 
that the Examiner's attempted combination lacks the requisite motivation. The Rouffet Court 
warned against "rejecting patents solely by finding prior art corollaries for the claimed elements" 
because that would "permit an Examiner to use the claimed invention itself as a blueprint for 
piecing together elements in the prior art." In re Rouffet, 149 F.3d at 1357. That approach was 
found by the Federal Circuit to be "an illogical and inappropriate process by which to determine 
patentability." Sensonics v. Aerosonic Corp., 85 F.3d 1566, 1570 (Fed. Cir. 1996). 
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The Examiner's general statement that including a "consecutive single file method of 
Kubota" in Spellman "would have given the user a high speed search for a document" does not 
satisfy the motivational requirements to make a proper §103 rejection. First, Kubota makes no 
distinction between the search speed that depends on whether it is a single file or multiple files. 
Second, Spellman does not disclose a search engine. Instead, Spellman relates to a "help" file 
hyperlink access procedure. A person of ordinary skill in the art would not have been motivated 
to combine a search engine looking for words phrases in a document search with Spellman f s 
hyperlink access to a second "help" file. There is certainly no evidence in either Spellman or 
Kubota that including Kubota's search technique would in any way speed up access to the second 
"help" file in Spellman. Thus, the Examiner fails to make a proper case of obviousness as 
required by the Federal Circuit, and therefore, the obviousness rejection must be withdrawn. 

But even if there was a proper motivation for combining Spellman and Kubota, (which 
there is not as demonstrated above), their combined teachings fail to disclose all of the features 
recited in the independent claims. For example and as already pointed out above, neither 
Spellman nor Kubota discloses browsing documents stored in the database, including a set of 
documents stored electronically as a single file, where at least one of those documents to be 
browsed includes references to other documents and/or files in the database. Spellman discloses 
a browser 126 in Figure 3. The help resource files 122 are located in a database an Internet site 
124, shown in Figure 3. Claim 1 recites "scanning the retrieved document to identify said links." 
Neither the remote server 130 at the Internet site 124 nor the browser control 128 at the Internet 
browser perform the claimed scanning of the retrieved second "help" file document. Although 
the windows "help" engine 138 retrieves a first "help" document 134 that includes a hyperlink, 
that first "help" document is not retrieved "in response to a request for that document by an 
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electronic document browser," as recited in claim 1. In other words, Spellman's browser 126 
does not retrieve the first "help" document. 

The Examiner is not consistent regarding the various entities in Spellman that allegedly 
perform the recited steps or functions recited in the claims. Scanning in Spellman is not 
performed on the retrieved document corresponding to the second "help" file, but rather on the 
first "help" file. If the Examiner is reading the retrieved document on the first "help" file, then 
that retrieval is performed by the windows help engine 138 — not the browser 126. 

Regarding of the feature "transforming the links into a format which is recognizable by 
the document browser," the Examiner identifies the ID codes and parameters inserted in the 
hyperlink link and transformed by a remote access macro 140 as corresponding to this feature. 
But this information insertion is not a step of transforming the document links into a browser 
format . 

In addition, Spellman fails to disclose the step of "transmitting the retrieved document 
including said transformed links to the browser." The second "help" file, which is retrieved from 
the second "help" database and forwarded to the browser, does not include "said transformed 
links." And the first "help" document retrieved by the windows "help" engine 138 is not 
transmitted to the browser 126. So in either situation, Spellman is deficient. 

Regarding independent claim 3, the Examiner does not address the step of "dynamically 
transforming the references of said retrieved document from a special, single file database syntax 
to a form said browser is capable of understanding." The hyperlink in the first "help" file is not a 
"special, single file database syntax." Claim 4 recites dynamic transformation of the references 
in the retrieved document "from a special syntax associated with a set of documents, . . .being 
stored as a single file in at least one of the databases to a form said browser is capable of 



- 13- 



BROK et al. 

Appl. No. 09/450,941 

September 3 a 2004 

understanding." Spellman does not disclose the special syntax in either claim 3 or 4 because, as 
the Examiner has already admitted, Spellman does not disclose storing a set of documents as a 
single file in a database. 

Accordingly, the combination of Spellman and Kubota fails to disclose the features of the 
independent claims as well as their respective dependent claims, including newly-added 
dependent claims 21-35. 

Not only does Spellman and Kubota combination fail to disclose all of the claim features, 
their combination (assuming it would even be made) makes no practical sense. Using a single 
file in Spellman complicates the addressing of the correct document, and the correct parts of the 
document, because additional references or parameters would have to be inserted in every 
hyperlink. The hyperlink in the first "help" file is fixed. As a result, if the location of the target 
file has changed, the hyperlink link (and possibly the IDs and parameters associated with the 
hyperlink) must be changed and reinserted into the "help" file to identify the new location. 
Moreover, whether the second "help" files are separate or combined into one single file does not 
impact management of the hyperlinks in the first help file. Either way, when the help file(s) is 
(are) relocated, for example to another server, the new location of the program code must be 
reinserted. Thus, combining Spellman and Kubota thus does not make sense and certainly does 
not provide the advantages of the present invention with respect to relocating a single file. In the 
present invention, when the single file location is changed, only the link for making the original 
request needs to be changed because the server or the external program handles the 
transformation of the links within the document. 

If the Examiner elects to maintain rejection of any claim in this case, Applicants 
respectfully request that the Examiner specifically identify the entity/element Spellman or 
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Kubota, (or any other prior art reference), which corresponds to each feature in the claim and 
which performs each step or function recited in the claims. 

The application is now in condition for allowance. An early notice to that effect is 
earnestly solicited. 
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